Wireless computer networks have become popular options for home and small business environments because they offer relatively inexpensive alternatives to traditional, wired computer networks and freedom of mobility for client devices such as notebook computers. However, concerns have been raised over the security, or lack thereof, offered by wireless networks. For example, it has been shown that wireless local area networks (WLANs) based on the IEEE (Institute for Electrical and Electronic Engineers) 802.11a and 802.11b standards are easily compromised by hackers, even if the hackers do not know specific user passwords for the networks beforehand.
The most recent IEEE WLAN specification, 802.1x, provides a roadmap for implementing improved WLAN security. In particular, an authentication server (which may be and external server, e.g., a RADIUS server, or may be combined with the wireless access point) is employed to verify user credentials before access to the network is granted. External authentication servers, such as RADIUS servers, are perhaps preferred in this arrangement because use of an external server avoids the need to store and manage authentication data on every access point of the WLAN, making the solution more scalable. In either case, however, authentication is user-based rather than device-based, so, for example, a stolen notebook computer does not necessarily imply a serious security breach.
Coupled with the use of authentication servers, the 802.1x specification calls for the use of an extensible authentication protocol (EAP) for negotiating a WLAN user's secure connection to the network. Security is handled by vendor-developed EAP authentication types, which may protect user credentials, provide data privacy, or both. For example, EAP-TLS (transport layer security) is used in the 802.1x client in Microsoft's Windows XP operating system to provide for certificate-based, mutual authentication of the client and the network. EAP-TLS also dynamically generates user- and session-based encryption keys that are distributed to the client and the access point to secure the connection.
EAP-TTLS (tunneled transport layer security) is another EAP authentication type co-developed by Funk Software and Certicom Corporation. EAP-TTLS is an extension of EAP-TLS that requires only server-side certificates, eliminating the need to configure certificates for each WLAN client. The protocol securely tunnels client authentication within TLS records, ensuring that the user remains anonymous to eavesdroppers on the wireless link and the entire network to the RADIUS server.
An example of the exchange between a client workstation 10 (e.g., a notebook computer with a WLAN interface card), called a supplicant in the language of the IEEE 802.1x standard, an access point 12 (which is terms an authenticator) a TTLS authentication server 14 and an authentication server 16 is shown in FIG. 1. This figure is adapted from “EAP Tunneled TLS Authentication Protocol”, IETF document “draft-ietf-pppext-eap-ttls-01.txt”, by Paul Funk and Simon Blake-Wilson, February 2002, (hereinafter “Funk and Blake-Wilson”) which is incorporated herein by reference. Note that in some cases, the functions of the TTLS server 14 and the authentication server 16 may be co-located on a single platform, but are shown separately in the diagram for clarity.
A complete discussion of the TTLS protocol is found in Funk and Blake-Wilson and will not be repeated herein. Briefly though, as shown in the diagram, the client 10 and access point 12 initiate an EAP conversation to negotiate the client's access to the network. Typically, the access point 12 begins the conversation by issuing an EAP-Request/Identity packet 101 to the client 10, which responds with an EAP-Response/Identity packet 102. Note that the client 10 does not include the user's actual identity in this EAP-Response/Identity packet 102; rather, the user's identity will not be transmitted until an encrypted channel has been established.
The access point 12 now acts as a passthrough device, allowing the TTLS server 14 to negotiate EAP-TTLS with the client 10 directly. During the first phase of the negotiation, the TLS handshake protocol is used to authenticate the TTLS server 14 to the client 10 and, optionally, to authenticate the client 10 to the TTLS server 14, based on public/private key certificates (see messages 103-113). As a result of the handshake, client 10 and TTLS server 14 now have shared keying material and an agreed upon TLS record layer cipher suite with which to secure subsequent EAP-TTLS communication.
During the second phase of negotiation, client 10 and TTLS server 14 use the secure TLS record layer channel established by the TLS handshake as a tunnel to exchange information encapsulated in attribute-value pairs, to perform additional functions such as client authentication and key distribution for the subsequent data connection (see messages 114-123).
If a tunneled client authentication is performed, the TTLS server 14 de-tunnels and forwards the authentication information to the authentication server 16. If the authentication server 16 performs a challenge, the TTLS server 14 tunnels the challenge information to the client (see messages 115-118). The authentication server 16 only needs to be able to authenticate the client based on commonly used authentication protocols.
Keying material for the subsequent data connection between client and access point may be generated based on secret information developed during the TLS handshake between client and TTLS server. At the conclusion of a successful authentication, the TTLS server 14 may transmit this keying material to the access point 12 (see messages 121 and 122), encrypted based on the existing security associations between those devices (e.g., RADIUS). The client 10 and access point 14 now share keying material, which they can use to encrypt data traffic between them.